Automation systems are traditionally designed to collect data from control and monitoring hardware, which is located near an industrial plant, process, or machine, and to concentrate the data at a control center. The traditional communication model has been to focus data from many sources for delivery to a few locations and recipients. At the control center, the information collected is continuously monitored by personnel and computer systems for appropriate operation of the field assets. To insure data delivery to the data center, the software and hardware components used in these systems must be operating and continuously connected by a network. Many users have implemented expensive and vast private networks to further insure the secure, reliable and timely delivery of data from field devices to the data center. The cost of these measures however, was deemed justified as the communication of conditions and circumstances in the field are vital to the safe and profitable operation of the industrial assets.
This approach however, is not adequate for the delivery of data to a large number of sites and recipients, does not reliably support the use of public networks that can reduce costs, and cannot insure the delivery of data to systems or users that may be intermittently connected to the network.
OPC (OLE for Process Control) is an interface standard that is commonly used to exchange data between industrial automation software programs. In this standard OPC Client application requests information from an OPC Server application, which processes the requests and serves up data to the client in response. A key consideration with regard to this architecture is that the Client and the Server must be active at the same time for data exchange to occur. In addition, OPC does not have means to compensate for communication latencies that can occur in wide area networks, does not provide for clients or servers intermittently connected to the network, and OPC data cannot be transferred over the Internet as it is usually blocked at corporate firewalls. The latter is because all TCP/IP ports except Port 80, which allows only textual data, are usually blocked at corporate firewalls. OPC however, is based on a Microsoft standard for component communication, DCOM (Distributed Component Object Model) that is not textual.
JMS (Java Messaging Service) is a messaging standard for disconnected transaction processing, which is commonly necessary in IT (Information Technology) applications. In this technology a computer system publishes data in the form of JMS messages to a message broker over a network. Subsequently, subscriber systems receive the latest data in the form of JMS messaging, from the message broker over the network. A key characteristic of this technology is that the publishing system and the subscriber system do not have to be connected to the message broker at the same time for the transaction to be completed. Additionally, JMS messaging is an appropriate method for the distribution of data over the Internet as the payload of the messages can be in the form of XML (Extensible Markup Language) which is text and which can pass through Port 80 in corporate firewalls.
The OPCMessenger is software that provides a bi-directional OPC to JMS bridge to:    a. Distribute data from automation systems to large numbers of users or applications over a network (The OPCMessenger enables a many sources to many recipients model.),    b. Insure delivery of data between automation systems and users or applications that may be intermittently connected to a network,    c. Collect and distribute data with secure and reliable delivery over public networks such as the Internet, and    d. Reliably deliver data between automation systems that may be widely separated and which may be connected by networks that may experience long latencies and service interruptions.
None of these capabilities has been economically possible through traditional industrial automation technologies, standards, protocols, or practices.